Now that you have become familiar with how to use the
helpful Upgrade Advisor, you’re ready to begin your extensive
pre-upgrade testing phase. After you resolve all the issues you can,
it’s time to take the next step: install SQL Server 2008 (in your test
and development environments first, of course).
Two different paths lead from SQL Server 2000 or 2005 to SQL Server 2008:
You can upgrade
your existing SQL Server 2000 SP4 or later and SQL Server 2005 SP2 or
later instances in-place, using the SQL Server Installer.
You
can install SQL Server 2008 side by side with your current SQL Server
instances and then migrate your data and other content to SQL Server
2008.
The same upgrade paths exist for upgrading from SQL Server 2008 to SQL Server 2008 R2.
The path you choose
depends primarily on two factors: your comfort level with the new
platform and the scope of feature use in your current environment. When
you have become familiar with what it takes to travel either path,
you’ll find it much easier to make your decision.
Note
If the server environment
where your current SQL Server installation resides is not a supported
platform for performing an in-place upgrade, a side-by-side migration
may be your only option. For example, if you are upgrading from SQL
Server 7 or running in a Windows 2000 server environment, an in-place
upgrade is not supported.
Side-by-Side Migration
SQL Server 2008 can
coexist without a problem on the same servers as any existing SQL Server
2000 or 2005 instances. SQL Server 2008 R2 can coexist on the same
servers as any existing SQL Server 2000, 2005, or 2008 instances. This
means you can install one or more instances of SQL Server 2008 or 2008
R2 without performing an in-place upgrade of any pre-2008 instances. You
don’t have to worry about whether you’re breaking existing
functionality. Side-by-side migration is therefore an easy option to
investigate.
Note
If you are doing a side-by-side
installation, be sure your server has sufficient resources (CPU, memory,
disk space) to support running multiple instances of SQL Server.
Many administrators favor
the side-by-side approach to upgrading because it gives everyone on the
development team (including eager software folks) a chance to get
comfortable with the new features in the new SQL Server release before committing to it in production environments.
In addition, it is far
easier to roll back to your previous-version SQL Server components
because installing side by side leaves them intact (unlike upgrading
in-place, which replaces them). When you are reasonably comfortable with
the new SQL Server release, you can go forward confidently in migrating
all your objects (presuming that, if you’re leaving previous versions
intact, you’re also ready to perform necessary tasks, such as changing
connection strings, server aliases, and so on).
Avoiding an Unintentional In-Place Upgrade During Setup
If you do intend to go ahead with
a side-by-side installation, there’s a small gotcha you need to watch
out for when installing a new instance of SQL Server 2008. When you run
the Setup program, the Instance Name screen is somewhat lengthy in its
header’s verbiage, and if you don’t take the time to read it closely,
you might unintentionally upgrade all your components. This is the
lowdown:
If you choose
the Default Instance radio button and you already have a SQL Server
default instance, that default instance is upgraded.
If
you the choose the Named Instance radio button, you need to make sure
to enter a name that you know is not in use as an instance name;
otherwise, the existing named instance is upgraded.
Figure 1 shows an example of how to make the right choice and use an instance name, SQL2008R2, that makes it abundantly clear you are installing a new instance.
Migrating Databases
Now
it’s time for the most important task: migrating your databases to SQL
Server 2008. One method of migrating to SQL Server 2008 or 2008 R2 is by
backing up your SQL Server 2000 and 2005 databases and restoring them
to SQL Server 2008. Another method is to attach or restore a database
from a prior version of SQL Server to SQL Server 2008. When you migrate
using either of these methods, the database is upgraded automatically
during the attach/restore process.
Note
Database backups
created by using SQL Server 7.0 or earlier are in an incompatible format
and cannot be restored in SQL Server 2008 or 2008 R2.
When you use backup and
restore to copy a database to another instance of SQL Server, the source
and destination computers can be any platform on which SQL Server runs.
The general steps to upgrade using backup and restore are as follows:
1. | Back
up the source database that resides on an instance of SQL Server 2000,
SQL Server 2005, SQL Server 2008, or SQL Server 2008 R2.
|
2. | Restore
the backup of the source database on the destination SQL Server.
Restoring the database automatically creates all the database files and
upgrades the database.
|
When restoring the database, you might need to use the MOVE
option to relocate the database files because SQL Server 2008 and SQL
Server 2008 R2 use a different default path than earlier versions.
In SQL Server 2008 R2, you can
also use the detach and attach operations to migrate a user database
from SQL Server 2000 or SQL Server 2005. After you attach a SQL Server
2005 or SQL Server 2000 or SQL Server 2008 database to SQL Server 2008
R2, the database is upgraded automatically and becomes available
immediately.
Another method of migrating an
existing database is by using the SQL Server Copy Database Wizard to
copy databases between multiple instances of SQL Server.
Tip
Before you use any of the methods described here, Microsoft recommends you run the appropriate DBCC consistency checks to make sure there is no data corruption within the databases to be migrated.
Using the Copy Database Wizard
Using the Copy Database
Wizard is probably the easiest approach to use to migrate your databases
to SQL Server 2008 or 2008 R2. To run the Copy Database Wizard, using
SQL Server Management Studio (SSMS), connect the Object Explorer to your
previous SQL Server version’s instance. Expand Databases and then select and right-click the database you want to copy (or move) into SQL Server 2008. Then select Tasks, Copy Database.
When the wizard’s initial
Welcome page is displayed, click Next and then select your source server
(the 2000 or 2005 instance). Click Next again and select your
destination server (your newly installed SQL Server 2008 or SQL Server
2008 R2 instance). Click Next again to bring up the Select the Transfer
Method screen. This screen provides two options for copying or moving
your databases to SQL Server 2008:
Detach and Attach—
This option is the same as the detach/attach method described
previously. It’s fast, but it takes the database offline during the
migration process.
Use the SQL Server Management Objects (SMO) to Import the Database— This option is slower, but it keeps the source database online during the process.
Note
When you use the detach and
attach method, SSIS uses the service account of SQL Server Agent that is
running on the 2008 (destination) instance. This account must be able
to access the file systems of both servers; otherwise, the wizard will
fail.
Select the option that works best for you and then click Next. The Select Databases screen appears, and, as Figure 2 shows, you should check the Copy (not Move) check boxes for the databases you want to migrate.
Caution
After a pre-2008 database is
upgraded (in case you choose the Move Database option or you perform an
attach or restore and delete the original), it cannot be downgraded back
to its former version—not even if you attempt to detach/attach or
restore it to SQL 2000 or 2005. Thus, it is especially important to
create full backup copies of all your databases before you upgrade. It’s
also a good idea to back up the entire Program Files/Microsoft SQL Server directory tree.
After you make your
database selections, click Next, and the Configure Destination Database
screen appears for each database you selected in the previous step. This
screen allows you to rename the database on the destination server if
you so desire (see Figure 3).
It also provides options to overwrite any existing databases or MDF
(data) and LDF (log) files on the destination server or to create new
ones in the folders of your choice. Make your selections and click Next.
The Select Database Objects screen that appears next (see Figure 4)
provides some real power because it allows the server-wide objects
(those stored in the system databases and source database) to be
imported. These objects include stored procedures residing in master,
SQL Server Agent jobs, custom user-defined error messages, SSIS
packages, and SQL Server logins. You need to click the ellipsis button
to choose the specific ones you want to import (rather than choosing
them all, which is the default).
When you’re finished
selecting the objects you want brought over, click Next again. The
Configure the Package screen that appears next provides the opportunity
to name and save the SSIS package created for migrating the database,
and to specify how you want to log the messages generated during the
transfer. Click Next to present the Schedule the Package screen, which
allows you to run the transfer immediately or schedule it to run at a
specific time. You are also given an opportunity to specify an SSIS
proxy account to use to run the transfer (you should make sure it’s an
account that has appropriate permissions on both the source and
destination servers to ensure a successful transfer).
After you make your scheduling choices, click Next to display the Complete the Wizard screen (see Figure 5).
Here, you have an opportunity to review the choices you’ve made on the
prior screens. If everything looks okay, click Finish to complete the
wizard and start or schedule the Copy Database package.
Database Compatibility Level
Migrating
pre-2008 databases into SQL Server 2008 brings up the question of
compatibility issues and database compatibility levels. The
compatibility level is a per-database setting that controls T-SQL
execution behavior with regard to SQL Server’s versioning system.
The T-SQL execution engine is
flexible insofar as it has the capacity to switch between varying,
version-dependent behaviors according to the current compatibility-level
setting.
When a database is upgraded
to SQL Server 2008 from any earlier version of SQL Server, the database
retains its existing compatibility level if it is at least 80 (SQL
Server 2000). Upgrading a database with a compatibility level below 80
sets the database to compatibility level 80.
Compatibility level
affects behaviors only for the specified database, not for the entire
server. An important point to understand about database compatibility
levels, however, is that the database compatibility-level setting is
intended to provide only partial backward compatibility with earlier
versions of SQL Server. It does not prevent the use of new T-SQL
features available in SQL Server 2008 such as new data types and
statements.
The compatibility-level
setting is provided primarily as an interim migration aid to work around
version differences in the behaviors that are controlled by the
relevant compatibility-level setting. Essentially, it allows T-SQL code
that may be using deprecated features or expects pre-100 level behaviors
for certain commands to continue operating as it did in the prior
version of SQL Server. Using the compatibility-level setting should not
be viewed as a permanent solution. It should be used only until the
T-SQL code affected by behavioral differences in SQL Server 2008 can be
converted to work properly in SQL Server 2008. Then you can use ALTER DATABASE to change the compatibility level to 100.
You can find a
full list of the behavioral differences between the compatibility-level
settings in the Books Online article associated with the “ALTER DATABASE
Compatibility Level” topic. This option can be used to set the
compatibility level for a particular database.
To view the current compatibility level of a database, query the compatibility_level column in the sys.databases catalog view:
select compatibility_level from sys.databases where name = db_name()
go
compatibility_level
-------------------
90
